It is widely known that when a personal computer is turned on, the basic input-output system (BIOS) that is stored in the non-volatile solid state memory of the computer is invoked to begin what is known as a “boot” process. The process of booting includes the various instantiation or initialization of select start-up activities and processes. A typically important task occurring during the booting process is the copying of an operating system from disk storage of the computer into volatile solid state memory, such as DRAM, of the computer. Once copied, execution of the operating system by the processor of the computer is readily undertaken.
Similarly, when the computer is turned off or when it is undergoes “re-booting,” the operating system is flushed from the volatile solid state memory. By executing the operating system from the relatively fast volatile memory instead of from the disk, computer operations are accelerated and consumers wait times are reduced.
It is also widely known that typically the BIOS code is independent of the specific operating system of a computer. For instance, conventionally, BIOS has been utilized in a single location, such as, e.g., cylinder 0, head 0, record 0, as the starting point from which to copy the operating system during system boot. The present invention understands that while this convention renders BIOS independent of particular operating systems, it restricts the loading of programs from disk during boot prior to loading the operating system, because the logical block addresses (LBAs) of the non-operating system programs are known only to the operating system and not to the BIOS.
As has become recognized, embedded or guest operating systems may need certain dynamic configuration data in order to sufficiently function, particularly at start-up. It is understood that storing configuration data (such as config files) should be away from where the data is to be used (i.e., separately), particularly as the real situation of modifying preference settings of programs where configuration is mutually stored may detrimentally impact the configuration data or setting of other programs. If the data is stored with the application program, or is otherwise centrally stored, a single point of failure possibility exists. Certain popular operating systems do not robustly separate their data resulting in effectively single points of failure for configuration data, where registry conflicts may readily cause setting information and configuration data for every program in the environment.
Additionally, though configuration data could be utilized through a file system on a HDD to store the information, given present commercial system configurations and non-standard inconsistencies, certain guest operating environments often lack the file system resource access or resource itself. Further the bootstrap application programs cannot simply be moved in their entirety to non-volatile BIOS memory, such as flash memory, primarily due to their size. Consequently, these applications must be booted from disk, yet need to be loaded prior to initiating a system boot.
As a result, it often proves a challenge to determine where the dynamic configuration data may be reliably situated. In certain situations, as is further set forth in FIG. 1A, a hypervisor, which as used herein is functionally a service provider of predetermined services to select operating systems in an operating environment, may logically reside above the hardware and below the operating systems in the operating environment. In certain other situations, a hypervisor may logically reside above a host operating system (HOS) residing above the hardware, and therefore virtualizes the hardware used by the one ore more lesser robust guest operating systems (GOS) residing above the hypervisor, as is exemplified in FIG. 1B.
The hypervisor of FIG. 1A is referred to herein as a “Type 1 hypervisor” and the hypervisor of FIG. 1B is referred to herein as a “Type 2 hypervisor.”
From FIG. 1A, a Type 1 hypervisor virtualization 100 includes a hypervisor 102 which typically resides directly above the hardware 103 and provide services for all the operating systems 101a, 101b, 101c. In this manner, of the operating systems, the HOS 101c is a special version of the GOS 101a, 101b and typically provides the device drivers for the hardware 103. The HOS 101c provides a means for the hypervisor 102 to provide virtualized devices for the remaining one or more GOS 101a, 101b. An example of a Type 1 hypervisor topology is the “Xen open source hypervisor.” In a Type 1 hypervisor virtualization, the GOS may include service operating systems (SOS), secure operating systems (SeOS) and similar secondary operating systems that logically reside as a peer to the HOS. Typically a GOS should be closely linked and capable of communication with the HOS, and typically SeOS are a less robust GOS, typically devoid of a user interface and often having available only one or no more than a few basic services (e.g., filtering of the network interface). As used herein, a Type 1 hypervisor virtualization is intended to be inclusive of any hypervisor virtualization where the GOS, SOS, SeOS or similar employs one or more services thereof (e.g., filters the network interface) for the HOS.
From FIG. 1B, a Type 2 hypervisor virtualization 105 includes a hypervisor 107 which typically does not have direct hardware 109 access. The hypervisor 107 is above the HOS 108 and below the one or more GOS 106a, 106b. An example of a Type 2 hypervisor is Microsoft's Virtual PC as the hypervisor runs on top of a native WinXP® system installation. In this manner, the Type 2 hypervisor can in turn host other WinXP®, Linux, etc., systems. In a Type 2 hypervisor virtualization, the GOS may include service operating systems (SOS), secure operating systems (SeOS) and similar secondary operating systems that logically reside above a host operating system (HOS). Typically a GOS should be closely linked and capable of communication with the HOS, and typically SeOS are a less robust GOS, typically devoid of a user interface and often having available only one or no more than a few basic services (e.g., filtering of the network interface).
Where there is no modifying term preceding the use of the term “hypervisor,” it is intended that the unmodified hypervisor term is of the Type 1 hypervisor.
Accordingly, what is needed is a system and method for loading programs during system boot using stored configuration data in a predetermined file system of a host operating system, prior to its operation, and providing the stored configuration data to one or more guest operating systems within the host operating environment, for its or their initialization.